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1. Welches technische Problem soil durch die Erfindung geldst werden? 



Mobile Endgeraete^jfaaiten beim NetauMng_eine Reihe von Konfigurationsparametern. Der'&£:;:0 $ 

Mechanismus ueber den diese Param^ertereagesfellt "^rdenrhaengfsehr-stark-vom ^'H^ 

Anwendungsscenario ab: 

• * 

Fuer mobile Endgeraete, die sich in einem lokalen Netzwerk (z.b. Hostspot) anrhelden, besteht diese 
Moeglichkeit oft hicht, da weder PPP nbch VPNs benutzt werden. Erfolgt kein Schutz der 
Konfigurationsdaten, so besteht die Moeglichkeit fuer einen Angreifer sowohl dem Endgeraet als auch 
dem Netzwerk Schaden zuzufuegen. Eine Beschreibung der Sicherheitsbedrohungen 1st unter anderem 
in [THREATS] zu finden. 

• ■ 

Ziel dieser Erfindung ist es daher einen Mechanismus zu definieren, der es mobilen Endgeraeten 
erlaubt Konfigurationsdaten gesichert zu erhalten. 



2. Wie wurde dieses Problem bisher geldst? -X • 

v. ■' 

Abbildung 1 zeigt die; Vielzahl der Protokolle, die bei einem Neti&werkzugang ausgefuehrt werden. Fuer 
dieggn Mechanismus sind speziell die Bausteine (2) und (3) vori interesse. Das Zusammenspiel dieser 
ijle wird in Abschnitt 5 erlaeutert. , 
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Abbildung 2: Protokollinteraktion beim Netwerkzugang 
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Der Mechanismus ueber den diese Parameter bereitgestellt werden, haengt sehr stark vom 
Anwendungsscenario ab; , 

• In Firmennetzwerken werden Konfigurationsparameter entweder statisch konfiguriert Oder 
dynamisch durch DHCP [DHCPv6] oder [RFC2131] erhalten. Meist findet dabei keine Schutz 
dieser Protokolle start. DHCP bietet jedoch die Moeglichkeit diese Nachrichten durch einen 
vorab ausgehandelten Schluessel zu sichem (siehe (RFC31 18]). 

* • 

• Fuer den Zugang zu einem Internet Service Provide wird nahezu ausschliesslich PPP (oder auch 
eine Variation PPPoE) benutzt, urn diese Konfigurationsdaten an das Endgeraet zu 
transportieren. 

■ 

• Fuer den VPN Zugang zu einem Netzwerk wurden in der Vergangenheit zwei Protokolle 
verwendet, um diese Konfigurationsdaten geschuetzt zu transportieren: ModeConfig und DHCP 
([Ric03], [Kiv03], [Duk02], [DP01]). Beide Verfahren wurden in das Authentifikations und 
Schluesselaushandlungsprotokoll IKE bzw. IKEv2 integriert. 



• • • ' - - ■ 

^ Urn sichere Konfigurationsdaten zwischen dem Netzwerk und dem- mobile Endgeraet zu ermoeglichen, 
wurden in der Vergangenheit unterschiedliche Methoden benutzt. Diese Methoden lassen sich grob in 
drei Gruppen aufteilen: 

* 

» 

• Erweiterungen zu DHCP 

Um DHCP Nachrichten im mobilen Umfeld zu schuetzen wurden eirie Reihe von Erweiterungen zum 
DHCP Protokoll vorgeschlagen (z.b. [MD+00], [MG+00], [MLOO] [Gup03]). Diese Vorschlaege sollen 
es einem Endgeraet erlauben sich dynamisch im Netzwerk eine Sicherheitsbeziehung mit dem 
DHCP Server aufeubauen. 



© EAP Methoden Erweiterungen 

Eine kuerzlich vorgeschlagene EAP methods (EAP-IKEv2 [TK03]) erlaubt es IKEv2 [IKEv2] 
wiede'rzuverwenden. Als ein Nebeneffekt besteht in IKEv2 die Moeglichkeit Konfigurationsdaten 
geschuetzt zu uebertragen. Zur Diskussion stehen dabei.^Wet Methoden: Modeconfig ([Duk02], 
[DP01]) und ein auf DHCP basierehder Ansatz ([Ric03], [Klv03]). 



o Bootstrapping Methode 




der Arbeit in der PANA IETF Arbeitsgruppe wurde an einem Protokollvorschlag gearbeitet, mit 
'n die initiate Netzwerkauthentifikation (mittles EAP) und die Bereitstellung einer 
Sicherheitsverbindung mit dem DHCP server ermoeglicht wird. Der Vorteil dieses Verfahrens liegt in 
der Trennung zwischen Netzwerkauthentifikation und der Sicherung der DHCP Nachrichten. Das 
DHCP Protokoll muss dabei nicht veraendert werden. 

3. In welcher Weise I6st di© Erflndung das angegebene technische Problem (Vortelle)? 

Die vorgeschlagenenen standard Konfigurationsprotokolle (DHCP/SWlodeconfig) ([Ric03],|£Kiv03] t |II 
[Duk02], [DP01]) werden benutzt um ein Endgeraet zu konifiguriert Dies geschieht in einer Art und 
Weise, die in diesem Umfeld noch nicht existiert Die Sicherung dieser Protokolle erfolgt durch die von 
der vorangegangenen EAP-basierten Netwerkauthentifikationsmechanismen bereitgestellten 
SchluesseL 

4. Worin liegt der erfinderische Schritt? 

Verwendung von existierenden Konfigurationsprotokollen (DHCP/Modeconfig) geschuetzt durch die 
atangegangene Netzwerl<zugangsauthentifikation. 

l * * 

eziellen sollen Mechanismen zur sicheren Uebertragung von Konfigurationsdaten fuer 
PEAP[PEAP] 
TTLS jTTLS] 
PANA [PANA] Oder als 

« eigene EAP seibst. Der Schutz dieser EAP Konfigurationsnachrichten erfolgt dabei sntweder 
ueber existierende Tunneling-Methoden (z.b. PEAP, TTLS, etc.) Oder durch EAP interne 
Schutzmechanismen (z.b. Protected TLV [HP+03]). Dabei ist es ebenfalls moeglich [GS03] als 
Container zu verwenden um die Konfigurationsdaten zu transportieren. 
definiert werden. 




5. AusfUhrungsbeispiel 

Der nachfolgende Nachrichtenfluss wurde aus Abschnitt 13.2 von [TTLS] entnommen und angepasst. 
Das Beispiel'zeigt den Aufbau eines TLS tunnels (einseitig Authentifikation; Server zu Client) mit 
anschliessender EAP/MD5-Challenge Authentifikation (einseitige Client zu Server Authentifikation). 

Fuer dieses Dokument ist die Uebertraung der Konfigurationsdaten nach Ende der Authentifikation 
entscheidend. In diesem Beispiel wird [Duk02] verwendet um den Client die Moeglichkeit zu geben,. 
Konfigurationsdaten mittels CFGJREQUEST anzufordern und ueber CFG_REPLY zu erhalten. Die 
VerWenriunn von DHCP ist riahesi his auf die Naohnnhtenforrnatp nleinh 
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2^?S^? 9U "? i er Konfigurationsdaten erfolgt dabei gesichert durch den TLS tunnel. Im Beispiel 
nicnt enthalten ist die Kommunikation zwischen dem TTLS server und dem Knoten. der die 
Konfigurationsdaten bereistellt (z.b. DHCP oder auch LDAP server). 

• * 

Anmei1<ung: Die Konfigurationsdaten koennen auch unmittelbar nach dem Ende der Authentifikation 
(z.d. mit der EAP success Nachricht) and das Endgeraet geschickt werden. 

p 

Client access point TTLS server AAA/H 




EAP-Request /Identity 

< . : — 

EAP-Response/Identity 

: > 




RADIUS Access-Request: 
XXX-^Data-Cipher-Suite-f- 

•EAP-Response passthrough 
, . > 

RADIUS Access-Challenge: 

EAP-Request /TTLS-Start 
< 



* s 



EAP-Request passthrough 
< 

EAP-Response /TTLS : 

ClientHello 
> 



"RADIUS Access-Request : 

EAP-Response passthrough 

r > 

RADIUS Access-Challenge: 
EAP-Request /TTLS : 
ServerHello 
Certificate 
ServerKeyExchange 

ServerHelloDone 

< . — 




i 



EAP-Request passthrough 
< 

( EAP-Response/TTLS: 

ClientKeyExchange 

ChangeCipherSpec 

Finished 
T > \ 

RADIUS Access-Request: 

EAP-Response passthrough 
> 

RADIUS Access-Challenge: 

EAP-Request /TTLS: * ' 

ChangeCipherSpec 

Finished 
< 

EAP-Request passthrough ' *' 

^ — — ~* ■"■ «• — — mm _______ n, 

EAP-Response/TTLS : 
' {EAP-Response/Identity} 

(XXX-Data-Cipher-Suite+J PlPST AVAILABLE COPY 

> 



B£err mm 



♦ « 
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v , EAP-Response passthrough . . 



> 



r • 



RADIUS - Access-Request: 

EAP-Re.sponse/Identity 
. > 

RADIUS Access-Challenge 
EAP-Request/ 

MD5-Challenge « 

* 

> 



RADIUS Access-Challenge: 
EAP-Request/TTLS : 

i EAP-Request /MD5-Challenge} 
{XXX-Data-Cipher-Suite} 

< ' : 




EAP-Request passthrough 
< . 

EAP-Response/TTLS : 

{EAP-Response/MD5-Challenge} 
1> 



RADIUS Access-Request: 

EAP-Response passthrough 

" ^ > ' 



RADIUS Access-Challenge 

EAP-Response / 

MD5-Challenge 
> 

RADlt?S~A-cci 

< 



RADIUS Access-Accept: 

XXX-Data-Cipher-Suite 

XXX-Data-Keying-Material 

EAP-Success . 
< , 



EAP-Success passthrough 
< ' 




EAP-Response/TTLS : 

CP(CFG_REQUEST) 



> 

RADIUS Access-Request: 

EAP-Response/TTLS passthrough 

CP(CFG_REQUEST) 

• . > 

♦ 

RADIUS Access-Challenge: 
EAP-Request /TTLS : 

CP(CFG REPLY) 

< Z 

EAP-Response/TTLS : 

CP(CFG_REPLY) 

< 

Abbildung 2: EAP-TTLS Protokoll mit Address-Konfiguration 
Als weiteres Ausfuehaingsbeispiel wird der Nachrichtenfluss in PANA dargestellt: 

♦ 

■ 

PaC PAA Message (tseq, rseq) [AVPs] 



PANA_dis cover (0, 0) 
PANA_start (x, 0) [Cookie] 

PANA &i-arir (\/ . fn.nnH pi 



B)att7/12 . Aktenzelch'en der GR . . : : 

< PANA_auth<x+l,y) [EAP{Requesc } ]. . : ~ - ~ • ■ 

PANA_auth(y+l, x+1) [ EAP{ Response } ] 

■ 

— < PANA_auth(x+2,y+l) [EAP{ Request}] 

> PANA_auth(y+2,x+2) [EAP {Response } ] ■ ' 

* 4 • 

— PANA SA Established — 

. < PANA_success<x+3,y+2) // F-flag set 

[EAP{ Success } , Device-Id, Data-Protection,. MAC] 
> PANA_sucbess_ack(y+3,x+3) 

[Device-Id, Data-Protection, CP (CFG_REQUESt£) , MAC] 

// F-flag Set 
< : PANA_msg(x+4,y+3) . . 

[CP(CFGJREQUEST), MAC] 1 

* 

Abbildung 3: PANA Prbtokoll mit Address-Konfiguration 

* ■ 

In Abbildung 3 wird das PANA Protokoll mit seinen Nachrichtenfluessen dargestellt. Die Erweiterungen 
zum PANA Protokoll sind minimal und beschraenken sich auf die Payloads zum Transport der 
Adresskonfigurationsnachrichten (DHCP/ModeConfig). In Abbildung 3 wurde das beispielhaft die 

«iurationspayloads aus [Duk02] verwendet. Die Anf rage und die Antwort zum Erhalt der 
lurationsdaten wird durch den MAC-Payload, der durch eine Keyed Message Digest Funktion 
srt wird geschuetzt. Die benoetigten Schluessel und Sicherheitsparameter werden. durch die 
Security Association (SA) bereitgestellt, die durch die EAP Authentication erzeugt wurden. 

Referensen: * ; 

[GS03] M, Grayson and J. Salowey: M EAP Authorization", Internet-Draft, (work in progress), March 

2003. 



[TK033 H. Tschofenig, D. Kroeselberg: "EAP IKEv2 Method", Internet-Draft, (work in progress), April 

2003. 

[RFC2409] D. Harkins, D. Carrel: "The Internet Key Exchange (IKE)", RFC 2409, November, 1998. 

[Ric03] M. Richardson: "A method for configuration of IPsec clients using DHCP", Internet-Draft, 

(work in progress), Februrary, 2003. 

[Duk02] D. Dukes: "Configuration payload", Internet-Draft, (work in progress), December, 2002. 
^todeConfig und DHCP , 

D. Dukes and R. Pereira: "The ISAKMP Configuration Method", Internet-Draft, (expired), 
September 2001 . 

[Kiv03] T. Kivinen: "DHCP over IKE", Internet-Draft! (work in progress), April 2003. 

i 

* i . 

[DHCPv6] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carney: "Dynamic Host 

Configuration Protocol for IPv6 (DHCPv6) f ', Internet-Draft, (work in progress), November, 
2002. 

[RFC2131] R. Droms: "Dynamic Host Configuration Protocol", RFC 2131, March 199.7. 

> • 

[RFC3118] R. Droms and W. Arbaugh: "Authentication for DHCP Messages", RFC 31 18, June 2001. 
[IKE] Harkins, D., Carrel, D, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. 

[IKEv2] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol", Internet-Draft, (work in progress), 

April, 2003. 

[HP+03] T. Hiller, A. Palekar, G. Zorn: "A Container Type for the Extensible Authentication Protocol 

(EAP)", Internet-Draft, (work in progress), May, 2003. 



Blatt 8/12 



Aktenzeichen der GR 



[PEAP] 



[TTLS] 



[PANA] 



Andersson, H., et al. "Protected EAP Protocol", Internet draft .(work in progress), February 
2002. 

» 

P. Funk, S. Blake-Wilson: "EAP Tunneled TLS Authentication Protocol", Internet draft (work 
in progress), February 2002. 

■ 

D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig and A. Yegin: "Protocol for Carrying 
Authentication for Network Access (PANA)", Internet-Draft, (work in progress), March, 2003. 



[THREATS] N. Prigent, J. Marchand, F. Dupont, B. Cousin, M. Laurent-Maknavicius, J. Bournelle: 

"DHCPv6 Threats", Internet-Draft, (expired), May 2001 . 



[MD+00] 



McAuley, A., Das, S M Madhani, S., Baba, S., Shobatake, Y.: "Dynamic Registration and 
Configuration Protocol (DRCP)", <draft-itsumo-drcp-01.txt> t (expired), July, 2000. 



[MG+00] Mukherjee, B M Gage, B., Liu, Y., Melzer, J.: "Extensions to DHCP for Roaming Users", 

<draft-muktierjee-dhc-dhcproam-00.txt>, (expired), October, 2000. 



[ML00] 



Medvinsky, S., Lalwaney, P.: "Kerberos V Authentication Mode for Uninitialized Clients", 
<draft-smedvinsky-dhc-kerbauth-01.M>, (expired), September 2000. 



I3] V. Gupta: "Flexible Authentication for DHCP Messages", Internet-Draft, (work in progress), 
February, 2003 



200308757 



Patentanspruch 

> 

Verfahren, bei clem ein mobiles ■ Endgerat gesichert 
Konfigurationsciaten erhait. 



